... 授權的檔案中。 【EPL-1.0 與 GPL 條款彼此互不相容】 EPL-1.0 也是具有授權拘束性的授權條款，原程式碼本身以及衍生程式均必須適用 EPL-1.0 授權，因此 EPL-1.0 程式碼無法改適用 GPL 授權。此外，由於沒有 MPL-2.0 的特別相容預設機制，所以也無法與 GPL 程式碼結合在同一個開發專案中相容並存。雖然 EPL-1.0 規定非衍生的獨立模組可以採用非 EPL-1.0 ...

...  針對這樣的運用方式，GPL-2.0、GPL-3.0、Apache-2.0、MPL-2.0 與 EPL-1.0 等授權條款，均有明確的文字，表示使用者可以透過收取費用的方式來提供額外的保證或擔保（註三）。而這種保證或擔保費用的收取，更是自由開源軟體的客製化承包商，得以生財牟利的彈性化商業應用模式。 值得注意的是，此類保證或擔保的承諾，是由特定使用者所自行提供，因此未來若是保證或擔保事由真的發生的話，也必須由這位特定的使用者自己來承擔保證或擔保責任，原自由開源軟體的授權人或其他的使用者，並不會連帶被課予這樣的保證或擔保責任。在一些授權條款中，有著明確的文字來闡明這樣的原則。所以若是因為某特定使用者額外提供的保證或擔保承諾，而使得授權人或其他使用者遭致損失或必須負擔額外責任的話，這位特定的使用者就必須協助授權人或其他使用者，來免於負擔這些額外的責任，而在授權人或其他使用者因此受有損失的情況下，這位特定使用者還必須要加以賠償這些無辜受殃者所遭遇的損失。 ...

...  其次，GPL-2.0、GPL-3.0、LGPL-2.1、LGPL-3.0、MPL-1.1、MPL-2.0、EPL-1.0 與 CDDL-1.0 這八份條款授權的元件，也是可以選擇的另外一種類別。這類授權條款都具有「授權拘束性（註二）」，原則上會拘束元件修改版本的授權方式，也就是修改後的衍生程式必須採用相同條款來授權，無法採用其他條款授權，例如元件原本採用 GPL-2.0 授權，修改後的版本也因此必須採用 ...

... sublicense 機制的條款，以在日後得以直接依條款規劃的機制處理上述問題。   【sublicense 於自由開源軟體領域的應用方式與差異】   右列幾款常見的自由開源授權條款，如：Apache-2.0、MIT、CPL-1.0、EPL-1.0、CDDL-1.0，以及 MPL-2.0（散布可執行檔格式時，註三），均有著明確容許 sublicense 的文字。所以如果使用者參與開發的是以這些授權方式進行共工的專案，授權規劃上，便可以在改作或是再行散布時，適當標註前專案與後專案之間的歷史關係，以及原創作人與創作團隊的顯名聲明之後，將後續專案轉以自己的名義向外授權。舉例來說，如果原來的自由開源軟體「AAA ...

... BSD-2-Clause、BSD-3-Clause（以下統稱這兩份授權條款為 BSD）、MIT、Apache-2.0、EPL-1.0、MPL-2.0、CDDL-1.0、GPL-2.0、GPL-3.0、LGPL-2.1、LGPL-3.0 與 AGPL-3.0 等，摘要式說明這些條款中與專利相關的規定，希望可以幫助有需要的朋友，能得到進一步掌握自由開源專利議題的參考資訊。     【未有任何專利相關明示規定的授權條款】 ...

...  而像 CPL-1.0 以及 Eclipse Foundation 專案下採用的 EPL-1.0（註七）也在條款中明文規定，為避免過多授權條款版本而產生不一致的問題，因此這些條款的使用者也無權修改條款文字內容，有權修改者僅為條款中所預先指定者，在 CPL-1.0 是 IBM 以及該公司所指派的條款管理者，在 EPL-1.0 是 Eclipse Foundation 以及該組織所指派的條款管理者。  ...